理论基础篇： https://wx.zsxq.com/group/48411118851818/topic/411244188545488

DDD（Domain-Driven Design，领域驱动设计）

DDD 是由 Eric Evans 在其著作《领域驱动设计：软件核心复杂性应对之道》中提出的软件设计方法。它不是一种具体的工程结构（如 MVC），也不等同于微服务架构，更不是单一的设计模式。

通过业务角度做区分，通过领域方式去代码结构进行处理。结合实际业务，以及工程设计角度，的一种指导思想（没有强制的某种范式）

DDD 核心聚焦：业务领域，解决核心复杂性；

如果业务不太复杂，其实也不用使用DDD，DDD主要的目的，还是类似解耦吧，通过业务领域纬度。

大的前提

• 1、领域划分
• 2、统一语言
• 3、限界上下文

实际使用的时候划分

• 实体
• 值对象（实际就是 Model )
• 聚合 AppService
• 领域服务 Service
• 仓储（Repository)

教程提到的一些概念：

充血模型 和 贫血模型

传统的 MVC 架构（Service + 数据模型）往往是“贫血模型”，导致 Service 层逻辑臃肿、难以维护；而 DDD 提倡“充血模型”，将属性和行为逻辑聚合在对象中，使代码结构更贴近真实业务逻辑

聚合对象

看教程，聚合对象更像是业务领域下的某个单独事务方法控制的动作场景。

适配器

端口，是对外提供的窗口

适配器，具体的实现。

在 DDD 架构中，调用外部接口遵循以下逻辑：

1. 定义标准（依赖倒置）：领域层不直接依赖外部的 RPC 或 HTTP 接口，而是定义一个含有出入参对象的接口标准（Port）。这被称为依赖倒置，即核心逻辑依赖于抽象接口，而不是具体实现。
2. 实现调用（适配器封装）：在基础设施层创建一个适配器类，注入外部服务的客户端（如 HttpClient 或 RPC 客户端），实现领域层定义的接口。
3. 防止污染（防腐层）：领域层只关心自身的业务模型，通过端口和适配器，外部系统的数据模型被转换成领域对象。这样即使外部接口发生变化，也只需要修改适配器代码，而不会污染核心领域逻辑